Skip to content

Refactor improve router response handlers #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Jul 14, 2025

Conversation

fulleni
Copy link
Member

@fulleni fulleni commented Jul 14, 2025

Status

READY/IN DEVELOPMENT/HOLD

Description

Type of Change

  • ✨ New feature (non-breaking change which adds functionality)
  • 🛠️ Bug fix (non-breaking change which fixes an issue)
  • ❌ Breaking change (fix or feature that would cause existing functionality to change)
  • 🧹 Code refactor
  • ✅ Build configuration change
  • 📝 Documentation
  • 🗑️ Chore

fulleni added 11 commits July 14, 2025 07:37
Introduces a new `ResponseHelper` class with a static `success` method.
This helper centralizes the logic for creating standardized `SuccessApiResponse`
objects, automatically populating metadata like the request ID and timestamp,
and serializing the final payload into a `Response.json` object.

This refactoring prepares the ground for simplifying the response-building
logic in various route handlers, reducing boilerplate code and improving
maintainability.
Moves the `RequestId` class from `routes/_middleware.dart` to a new,
more appropriate location at `lib/src/models/request_id.dart`. This
resolves an architectural issue where a helper class in `lib/` could not
access a model defined in `routes/`.

All references to `RequestId` in the root middleware and the new
`ResponseHelper` have been updated to use the new, correct import path.
This change improves code structure and enables further refactoring.
Updates the `/api/v1/auth/anonymous` route handler to use the new
`ResponseHelper.success` method. This change removes several lines of
boilerplate code related to manually creating metadata and the success
response object, making the handler cleaner and more focused on its
core logic.
Updates the `/api/v1/auth/me` route handler to use the new
`ResponseHelper.success` method. This change removes several lines of
boilerplate code related to manually creating metadata and the success
response object, making the handler cleaner and more focused on its
core logic.
Updates the `/api/v1/auth/verify-code` route handler to use the new
`ResponseHelper.success` method. This change removes several lines of
boilerplate code related to manually creating metadata and the success
response object, making the handler cleaner and more focused on its
core logic.
Updates the `/api/v1/auth/verify-link-email` route handler to use the new
`ResponseHelper.success` method. This change removes several lines of
boilerplate code related to manually creating metadata and the success
response object, making the handler cleaner and more focused on its
core logic.
Updates the `/api/v1/data/index.dart` route handler to use the new
`ResponseHelper.success` method for both GET and POST requests. This
change removes several lines of boilerplate code related to manually
creating metadata and the success response object, making the handler
cleaner and more focused on its core logic.
Corrects a type error in the `data/index.dart` route handler where the
`toJsonT` closure passed to `ResponseHelper.success` was returning a
`dynamic` type instead of the required `Map<String, dynamic>`.

This change adds an explicit cast to `Map<String, dynamic>` on the
result of the inner `toJson()` call, satisfying the Dart type checker
and ensuring type safety.
Updates the `/api/v1/data/[id]/index.dart` route handler to use the new
`ResponseHelper.success` method for both GET and PUT requests. This
change removes several lines of boilerplate code related to manually
creating metadata and the success response object.

It also removes the now-unnecessary `requestId` parameter from the
internal handler functions, making the code cleaner and more focused
on its core logic.
@fulleni fulleni merged commit eaee368 into main Jul 14, 2025
1 check failed
@fulleni fulleni deleted the refactor_improve_router_response_handlers branch July 14, 2025 07:07
Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Summary of Changes

Hello @fulleni, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on enhancing the API's response handling by introducing a centralized ResponseHelper to standardize success responses, thereby reducing redundant code in various route handlers. It also improves code organization by relocating the RequestId class to its own file and includes general code cleanup and formatting improvements.

Highlights

  • Standardized API Responses: Introduced a new ResponseHelper utility class (lib/src/helpers/response_helper.dart) to centralize and standardize the creation of successful JSON API responses. This helper encapsulates the logic for generating ResponseMetadata and wrapping data in SuccessApiResponse, reducing boilerplate in individual route handlers.
  • Code Organization: The RequestId class, which provides a unique identifier for each incoming HTTP request for traceability, has been moved from routes/_middleware.dart to its own dedicated file (lib/src/models/request_id.dart). This improves modularity and maintainability.
  • Route Handler Refactoring: Multiple route handlers across the routes/api/v1/auth/ and routes/api/v1/data/ directories have been refactored to utilize the new ResponseHelper.success method. This significantly cleans up the response generation logic in these files.
  • Logging Cleanup: Removed explicit [ReqID: $requestId] prefixes from print statements within data handlers, as the RequestId is now managed and accessed more cleanly via the RequestContext and ResponseHelper.
  • Minor Fixes and Formatting: Included minor formatting adjustments across several files for improved readability and a small fix in lib/src/services/database_seeding_service.dart to correctly use a raw string literal for MongoDB update operations.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in issue comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request is a great refactoring that introduces a ResponseHelper to standardize API success responses, and moves the RequestId model to a more appropriate location. This significantly reduces boilerplate code in the route handlers.

My main concern is that the requestId has been removed from several log messages (print statements) in routes/api/v1/data/[id]/index.dart. The requestId is crucial for tracing and debugging requests, and removing it from server-side logs undermines its purpose. I've added specific comments with suggestions to re-introduce the requestId into the logs.

Overall, the refactoring is a solid improvement, and once the logging concern is addressed, this will be ready to merge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant